2019-20 / SaaS / Booking / Web - Tablet

Helping restaurants manage their own availability without calling support

Helping restaurants manage their own availability without calling support

~60%

~60%

reduction in support tickets

reduction in support tickets

~94%

~94%

Reduction in Schedule Conflicts

Reduction in Schedule Conflicts

My Role

Senior Product Designer — Business Centre:

Analysed support tickets, audited the existing calendar, and designed a new Booking Availability view and Special Closing Days flow. Also scoped the full calendar replacement for phase 2. Sole designer, working with a PM and engineers throughout.

The challenge

Quandoo was a global restaurant reservation platform. Restaurants used its Business Centre tools to manage tables, bookings and when they took reservations. I was the sole designer on those tools, working with a PM and engineers in the product focus team.

Restaurants needed to change their availability often, and usually at short notice. The tools to do it existed, but most restaurants contacted support instead.

Existing Calendar view where restaurant schedules were managed

Limitations & considerations

We couldn't change everything at once. The admin section had not been a priority design wise for years, so the area was dumping ground for fragmented flows with the bare minimum user experience considered.

We didn't have the time or resources to overhaul the Business Centre so our solutions had to update the experience gradually, building on what was already there, without breaking things for restaurants and creating doubts and uncertainty about a tool they used daily.

Discovery

Grouping Intercom tickets showed the same nine or ten requests on repeat. Blocking bookings, unblocking them, fixing opening times and explaining errors.

An audit of the Calendar with the team showed why. Six overlapping colour codes, no visible status, no view of upcoming changes and no guardrails on edits. The most common complaint summed it up: "It didn't work, people are still able to reserve."

From there, we wrote a hypothesis for each problem area, tied to a specific Intercom category. Mapping every use case showed two jobs tangled together: seeing what's coming up, and closing specific dates. That became the two parts of the redesign.

Problems

No clear view of the days ahead. The Calendar packed everything into one dense grid, with six overlapping colour codes and no status. Checking if tonight was open meant decoding it, so staff often called instead

No simple way to close. Holidays and private events meant closing for a day or more. With nowhere dedicated to do it, restaurants asked support to block dates, or tried workarounds that let bookings through.

Hypotheses

If restaurants could see the week ahead at a glance, and close specific dates in a few clear steps, they would manage their own availability. Fewer calls to support, fewer missed changes, and more trust in the tools they already had.

We'd know it was working when schedule-related requests in Intercom dropped.

Front-desk teams were drowning. Hundreds of messages a day — prescriptions, rescheduling, routine inquiries — all manually routed by staff who should've been focused on patients.

We built a three-step automation builder: pick message type, choose action, set scope. Simple enough that admins actually used it.

~14% of messages now auto-route, saving teams several hours a week.

Solutions

Solutions

  1. 01)

    Upcoming special closing times

    An overview of upcoming changes to the standard schedule that lives alongside the current calendar

  2. 02)

    Simplified calendar

    A new veriosn of the exisiting calendar to replace the clunky and visually complex boilerplate currently used

Part 1.
Part 1.

Upcoming Special exception times

Upcoming Special exception times

We first wanted to highlight active Special Exceptions as these were the high stakes setting in the admin areas and the ones that, if wrong, caused big problems involving missed, blocked, and double bookings.

A new module added to the top of the page above the existing calendar showed all the next 5 upcoming special closures the restaurant had scheduled, surfacing information that was previously just hidden in the bloated calendar view.

As the vast majority of our traffic was on desktop, we utilised tooltips to give admins a quick view of the closure details. Clicking the row opens up the detail/edit view for all of the info.

We also added a number of guardrails to the process of making changes to opening times that were not previously available by surfacing when changes would affect a time slot with existing bookings, warning restaurant admins and offering paths to addressing the issues.

Part 2.
Part 2.

Simplified calendar view

Simplified calendar view

The old calendar was replaced by a more structured module designed on a grid reflecting the standard setup most restaurants followed, allowing a condensed overview of the restaurant schedule .

New calendar

New calendar

Old calendar

Old calendar

The long list of literal time slots were replaced by a stripped block format which better matched the majority of setups we saw in the Business centre.

That increased how scannable the information was and gave us a space to clearly communicate any useful context needed. The simpler, less noisy UI also let the rest of the page breath and allowed other elements to remain prominent and in the correct context.

The long list of literal time slots were replaced by a stripped block format which better matched the majority of setups we saw in the Business centre.

That increased how scannable the information was and gave us a space to clearly communicate any useful context needed. The simpler, less noisy UI also let the rest of the page breath and allowed other elements to remain prominent and in the correct context.

Putting it all together

Putting it all together

By adding individual modules with isolated workflows attached, we were able to updated the experience within the framework of the existing Business centre architecture and patterns.

Phase 1

Inserted the Special exceptions list and Standard availability panel above the existing calendar section in order to surface hidden functionality and bring clarity to the settings currently applied in the area.

Phase 2

Added our new simplified calendar and gave that the primary place on the page as it was the most used and most useful element for our customers, with our Special exceptions list and Standard availability panel sitting beneath but still with high prominence in the view owing to the new calendar's focussed, shortened design.

Other changes
Other changes
  • Changed section name from "Calendar" to "Booking availability" after testing naming options with customers

  • Updated flows attached to the section's functionality including editing a time slot and setting and editing special exceptions

  • Updated and rebuilt a number of related components, including calendar date picker & navigation, icons, grids for sub-pages, and more

Example scenario for amending special closing times flow. One of 4 main scenarios linked to editing the details in the Booking Centre

Outcomes

We were able to bring a much neglected but vital section of Quandoo's offering up to date, finding ways to improve the experience without fully rebuilding a complex legacy system that was not a business priority.

And we did it in stages which actually allowed the work to make it on to the roadmap and got tangible improvements into customers hands quickly.

~60% reduction in support tickets by replacing complex hourly calendar grids with clear weekly service blocks and an at-a-glance availability calendar.

94% reduction in restaurant schedule-conflict incidents and near-total elimination of ghost-booking escalations through active guardrails intercepting hours updates.

3.5 minutes to under 45 seconds task completion time to set holiday hours and closures by swapping dense timeline matrices for streamlined visual cards.

Learning & reassessing

Although we successfully updated the Calendar/Booking availability, retro fitting an existing view with modules proved about as time consuming as designing a new view entirely from a purely design and build point of view.

That being said, the breathing room given to us by designing in modules was vital in allowing us the space to carry out discovery as we went on a project where carving out that space upfront was difficult due to other upcoming priorities and bottlenecks with larger UX research tasks.

✧